Skip Headers

Oracle® Database Backup and Recovery Reference 10g Release 2 (10.2) Part Number B14194-03 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# RESTORE

Syntax

restore::=

Description of the illustration restore.gif

restoreObject::=

Description of the illustration restoreobject.gif

restoreSpecOperand::=

Description of the illustration restorespecoperand.gif

autoBackupOptList::=

Description of the illustration autobackupoptlist.gif

Purpose

The primary use of RESTORE is to restore files from backups or image copies. Typically, you restore when a media failure has damaged a current datafile, control file, or archived log or prior to performing a point-in-time recovery.

There are other uses of RESTORE that do not actually restore files from backup:

- RESTORE... VALIDATE causes RMAN to select existing backups that it would use to perform a RESTORE operation, and scan them all to ensure that they are present and free of corruption.

- RESTORE... PREVIEW identifies the backups which RMAN will use to perform any RESTORE operation. Output from a RESTORE... PREVIEW is in the same format as the output of the LIST command.

- RESTORE... PREVIEW RECALL is used to request the recall of backups needed for a RESTORE operation that are stored on remote storage.

RMAN chooses which backups to restore based on the criteria that you specify. For example, you can limit the restore to backups before a given point of time (within the current incarnation) with the untilClause.

Locations of Restored Files

If you restore to the default location (that is, you do not run SET `NEWNAME`), then RMAN overwrites files with the same filenames. If you restore to a new location, then issue `SET` `NEWNAME` commands to rename the files and issue a SWITCH command to make the restored files current. If you do not issue `SWITCH` commands, then RMAN considers the restored files as valid copies for use in future restore operations.

If you do not run `SET` `NEWNAME` and RMAN detects that the default filename cannot be used (for example, because the filename is in use by another database that shares the storage), and if the file is an Oracle Managed File or is on an Automatic Storage Management disk group, then RMAN attempts to create a new file in the same location or disk group.

Note: By default, RMAN does not restore a datafile if the file is in the correct place and its header contains the expected data (RMAN does not scan the datafile body for corrupt blocks). The `FORCE` option overrides this behavior and restores the requested files unconditionally.

Channel Allocation in a Restore

If you do not manually allocate channels, then RMAN allocates all automatic channels possibly needed by the `RESTORE` command, subject to any restrictions imposed by the use of the `DEVICE` `TYPE` option.

For example, assume you configure 3 separate `sbt` channels (each with different `PARMS`) and then configure parallelism for `DISK` and `sbt` as follows:

    CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
    CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
    CONFIGURE DEFAULT DEVICE TYPE TO sbt;

If you run `RESTORE` in this configuration, then RMAN allocates three `sbt` channels and the two preconfigured `DISK` channels.

Restore Failover

If a backup piece, image copy or proxy copy is inaccessible (for instance, deleted from the device) or if a block is corrupted, then the RESTORE command automatically looks for a another usable copy of this backup piece or image copy on both the same device and other devices. If no usable copies are available, then RMAN searches for prior backups. RMAN continously searches for prior usable backups until it has exhaused all possibilities.

Restore failover also occurs when restoring archivelogs for use in RECOVER, BLOCKRECOVER and FLASHBACK operations. RMAN records messages about failover due to block corruption in the alert log and trace files.

See Oracle Database Backup and Recovery Advanced User's Guide for details on restore failover.

Restoring from Encrypted Backup Sets

How RMAN handles encrypted backup sets during restore operations depends upon the encryption mode with which the backup was created.

- For transparent-mode encrypted backups, the required passwords must be available in the database wallet. This means that the same wallet that was used when creating the backup must be open, and available, when restoring it. No SET `DECRYPTION` command is required.

- For password-mode encrypted backups, the required passwords must be provided using SET `DECRYPTION`.

- For dual-mode encrypted backups, the required passwords must be available in the database wallet or provided using SET `DECRYPTION`.

For an overview of the encrypted backups mechanism, a guide to its use and information on choosing among the different modes of encryption, see "Encryption of Backup Sets" and the extended discussion in Oracle Database Backup and Recovery Advanced User's Guide.

The RMAN CONFIGURE, SET and SHOW commands are used to manage the RMAN backup encryption settings for your database. See the reference entries for those commands for more details.

Restoring Files in a Real Application Cluster Configuration

In a Real Application Clusters configuration, RMAN automatically restores backups, control file copies, and datafile copies from channels that can read the files on tape or a local file system. For example, if channel 1 connected to instance 1 can read log 1000 from its tape drive, but channel 2 connected to instance 2 cannot read the same log from its tape drive, then channel 1 restores the log. Autolocation is automatically enabled when the channels meet any of the following criteria:

- Different `PARMS` settings

- Different `CONNECT` strings

  See Also: Oracle Database Backup and Recovery Basics to learn how to restore files

Restrictions and Usage Notes

- To restore datafiles to their current location, the database must be started, mounted, or open with the tablespaces or datafiles to be restored offline. If the database is started but not mounted, then it is recommended that you only restore the control file, if necessary (refer to "Restrictions and Usage Notes for RESTORE CONTROLFILE"). To restore other files, mount the database and then continue.

  Note: When performing a database validation by using `RESTORE` `...` `VALIDATE`, the database can be open.

- To restore to a new location, run `SET` `NEWNAME` commands to rename the datafiles and SWITCH commands to make them the current database files. If you do not use `SWITCH`, then the repository lists restored datafiles as datafile copies.

- If you use the `FROM` `DATAFILECOPY` option, then the allocated channels must be of `DEVICE` `TYPE` `DISK`.

- If you use the `FROM` `BACKUPSET` clause, then channels for the appropriate type of storage devices must be allocated for the backup sets that need to be restored. For example, if needed backups are only available on tape, and no SBT channels have been allocated, then RMAN cannot find a candidate backup set to restore, and the `RESTORE` command fails.

- RMAN only restores backups that were created on the same type of channels that are allocated for the `RESTORE` command.

  For example, if you made some backups of a datafile to `DISK` channels and others to `sbt` channels, and only a `DISK` channel is allocated for the `RESTORE` command, RMAN will not restore backups that were created on `sbt` channels.

- If there are no backups available for a lost datafile, RMAN will create an empty datafile with the checkpoint change as creation SCN. During recovery, all archived logs back to the creation of the datafile will be restored, and all changes during the history of the datafile will be re-applied to re-create its contents.

- If datafile names are symbolic links, that is, files pointing to other files, then the control file stores the filenames of the link files but RMAN performs I/O on the datafiles pointed to by the link files. If a link file is lost and you `RESTORE` a datafile without re-creating the symbolic link, then RMAN restores the datafile to the location of the link file rather than to the location pointed to by the link.

- If the database is started but not mounted in `NOCATALOG` mode, then the `RESTORE` `SPFILE` command requires the `FROM` `AUTOBACKUP` clause.

- If you are restoring the server parameter file and the control file in a disaster recovery situation, you cannot run `RESTORE` `CONTROLFILE` `FROM` `AUTOBACKUP`, mount this control file, and then run `RESTORE` `SPFILE` without the `FROM` `AUTOBACKUP` clause.

- Do not specify a datafile more than once in a restore job. For example, the following command is illegal because `datafile` `1` is both specified explicitly and implied by the `SYSTEM` tablespace:

      RESTORE TABLESPACE SYSTEM DATAFILE 1;

- You must have already configured a device type by using `CONFIGURE` (except for `DISK`, which is preconfigured) before specifying the `DEVICE` `TYPE` option.

- You cannot manually allocate channels and then run `RESTORE` `DEVICE` `TYPE`.

- When you run `RESTORE` with a backup control file while connected to a recovery catalog, RMAN automatically updates the control file to reflect the structure of the restored database, based on the information in the recovery catalog.

- RMAN can back up and restore dictionary-managed temporary tablespaces, but it cannot back up locally managed temporary tablespaces. It can, however, re-create locally managed temporary tablespaces after a database restore.

- RMAN does not support backup and recovery of the change tracking file. Note that database restore and recovery has no user-visible effect on change tracking. The change tracking file is re-created upon database restore and recovery, and the next incremental backup after any recovery is able to use the change-tracking file.

- If no suitable backups are available in the current incarnation of the database, then you can force RMAN to use backups from a previous incarnation. Using the CHANGE... UNAVAILABLE command, you can make all backups since the RESETLOGS that ended the incarnation unavailable. Run LIST `RECOVERABLE` to see valid parent incarnations.

Restrictions and Usage Notes for RESTORE CONTROLFILE

- After you restore a backup control file, you must run `RECOVER` `DATABASE` and then open the database with the `RESETLOGS` option.

Table 2-27 indicates the restrictions that apply in different situations involving the `RESTORE` `CONTROLFILE` command.

Table 2-27 RESTORE CONTROLFILE Scenarios

| RESTORE CONTROLFILE; | RESTORE CONTROLFILE FROM AUTOBACKUP; | RESTORE CONTROLFILE ... TO 'filename'; | RESTORE CONTROLFILE ... FROM 'media_handle' or TAG 'user_tag';
--- | --- | --- | --- | ---
No catalog, target started in NOMOUNT state | Error. Must specify `FROM` `AUTOBACKUP`. | First run SET `DBID`. Restores to `CONTROL_FILES` locations. | First run SET `DBID`. Must specify `FROM` `AUTOBACKUP`. Restores only to `filename`. | First run SET `DBID`. Restores from specified file (cannot restore from `TAG`). If `TO` '`filename`' not used, restores to all `CONTROL_FILES` locations.
No catalog, target mounted or open | Error. Must use `TO` '`filename`', where `filename` is not in `CONTROL_FILES` list. | Error. Must use `TO` '`filename`', where `filename` is not in `CONTROL_FILES` list. | Restores only to `filename`, where `filename` is not in `CONTROL_FILES` list. | Restores from specified file. If `TO` '`filename`' not used, restores to all `CONTROL_FILES` locations.
Catalog, target started in NOMOUNT state | Restores to `CONTROL_FILES` locations. Run SET `DBID` only if `DB_NAME` not unique in catalog. | Only use with catalog for testing purposes. | Restores only to `filename`, where `filename` is not in `CONTROL_FILES` list. | Restores from specified file. If `TO` '`filename`' not used, restores to all `CONTROL_FILES` locations.
Catalog, target mounted or open | Error. Must use `TO` '`filename`', where `filename` is not in `CONTROL_FILES` list. | Do not use with catalog. | Restores only to `filename`, where `filename` is not in `CONTROL_FILES` list. | Restores from specified file. If `TO` '`filename`' not used, restores to all `CONTROL_FILES` locations.

Restrictions and Usage Notes on RESTORE... PREVIEW

Backup media may be stored remotely, whether in a backup vaulting scenario where media is shipped to an off-site location, or in a tape library where media is on-site but not immediately accessible. Some media managers maintain information about whether the media containing specific backups is stored remotely, and make this information available to RMAN.

Backups stored remotely are marked as AVAILABLE in the RMAN repository, even though the media must be retrieved from storage before the backup can be restored. If RMAN attempts to use a remotely stored backup in a RESTORE operation, the RESTORE operation fails.

You can use RESTORE... PREVIEW to identify backups RMAN needs for a RESTORE operation that are stored on media that requires retrieval. The output of RESTORE... PREVIEW indicates whether backups are stored remotely. If a needed backup is stored remotely, your options are:

- Use CHANGE... UNAVAILABLE to prevent RMAN from selecting the needed remote backups, and attempt the RESTORE... PREVIEW operation again to see if RMAN selects another remote backup. When RMAN does not select any remote backups, you can perform your RESTORE operation.

- Use RESTORE... PREVIEW with the RECALL option. If your media manager supports this functionality, RESTORE... PREVIEW RECALL automatically requests the retrieval of the remotely stored backup media. Use RESTORE... PREVIEW again, periodically, to monitor whether the needed backups are stored locally again.

Keywords and Parameters

restore

Syntax Element | Description
--- | ---
`CHANNEL` `'channel_id'` | Refer to the `restoreSpecOperand` clause.
`CHECK` `LOGICAL` | Tests data and index blocks that pass physical corruption checks for logical corruption, for example, corruption of a row piece or index entry. If RMAN finds logical corruption, it logs the block in the `alert.log` and server session trace file. If the total number of physical and logical corruptions detected in a file is less than its `MAXCORRUPT` setting, the RMAN command completes and the database populates the `V$DATABASE_BLOCK_CORRUPTION` view with corrupt block ranges. If `MAXCORRUPT` is exceeded, the command terminates without populating the views. If the initialization parameter `DB_BLOCK_CHECKSUM=TRUE`, and if `MAXCORRUPT` and `NOCHECKSUM` are not set, then specifying `CHECK` `LOGICAL` detects all types of corruption that are possible to detect. Note: The `MAXCORRUPT` setting represents the total number of physical and logical corruptions permitted on a file.
`CHECK` `READONLY` | Checks the read-only datafiles to make sure they exist, are readable, and have the appropriate checkpoint. If any of these conditions is not met, then RMAN restores the files—whether or not they are read-only. By default, RMAN does not restore read-only files when you issue the `RESTORE` `DATABASE` command.
`DEVICE` `TYPE` deviceSpecifier | Allocates automatic channels for the specified device type only. For example, if you configure automatic disk and tape channels, and issue `RESTORE``...``DEVICE` `TYPE` `DISK`, then RMAN allocates only disk channels. See Also: "deviceSpecifier"
`FORCE` | Overrides the restartable restore feature and restores all files regardless of whether they need to be restored. If you do not specify `FORCE`, then RMAN restores a file only if its header information does not match the information in the control file.
`FROM` `[ BACKUPSET` `|` `DATAFILECOPY ]` | Specifies whether RMAN should restore from a `DATAFILECOPY` on disk or a `BACKUPSET`. By default `RESTORE` chooses the most recent backup set or file copy, that is, the file copy or backup set that needs the least media recovery.
`FROM` `TAG` `=` `'tag_name'` | Refer to the `restoreSpecOperand` clause.
`PREVIEW` `[ SUMMARY | RECALL ]` | When `PREVIEW` or `PREVIEW` `SUMMARY` is appended to any `RESTORE` command, instead of performing the restore RMAN will report the backups (on disk or sequential media) it will use during the restore. The output will be in the same format as is generated by the `LIST` `BACKUPS` and `LIST` `BACKUPS`... `SUMMARY` commands. Some media managers provide status information to RMAN about which backups are vaulted, that is, stored in a remote location such as a secure storage facility, and which therefore cannot be used without retrieving media. The output of `RESTORE` identifies such backups, if the media manager provides the necessary information. When used with the `RECALL` option, `RESTORE`... `PREVIEW` initiates a request for the retrieval of backup media needed for the specified restore operation from remote storage. See Also: "LIST", and specifically the `BACKUPS` and `SUMMARY` options.
untilClause | Limits the selection to backup sets or file copies that are suitable for a point-in-time recovery to the specified time. In the absence of any other criteria, RMAN selects the most current file copy or backup set to restore. Note that the time specified in the untilClause must fall within the current incarnation. See Also: "untilClause"
`VALIDATE` | Lets RMAN decide which backup sets, datafile copies, and archived logs need to be restored, and then scans them to verify their contents. No files are restored. Use `VALIDATE` to verify that the backups required to restore the specified files are intact and usable.

restoreObject

Syntax Element | Description
--- | ---
`restoreObject` | Specifies the objects to be restored. The `RESTORE` command restores full backups, incremental backups (level 0 only), or copies of datafiles, control files, and archived redo logs.
archivelogRecordSpecifier | Restores the specified range of archived redo logs. The default restore location is `DB_RECOVERY_FILE_DEST` (if one of `LOG_ARCHIVE_DEST_n` is configured to `USE_DB_RECOVERY_FILE_DEST` either implicitly or explicitly). Otherwise, the default restore filenames are constructed with the `LOG_ARCHIVE_FORMAT` and `LOG_ARCHIVE_DEST_1` parameters of the target database. These parameters combine in a port-specific fashion to derive the name of the restored log. You can override the default location with the SET `ARCHIVELOG` `DESTINATION` command. Because the RECOVER command automatically restores archived logs as needed, you should seldom need to restore logs manually. Possible reasons for manually restoring archived logs are to speed up recovery or to stage the logs to multiple destinations. See Also: "archivelogRecordSpecifier" Note: The database can be started, mounted, or open for this operation.
`CONTROLFILE` | Restores the current control file for a primary database. See Also: Table 2-27 for restrictions and usage notes. Note: You must always run the RECOVER command after restoring a control file, and must also always open the database with the `RESETLOGS` option.
`DATABASE [ SKIP [ FOREVER ] TABLESPACE tablespace_name ]` | Restores all datafiles in the database except those that are offline or read-only. Unlike `BACKUP` `DATABASE`, `RESTORE` `DATABASE` does not automatically include the control file and the server parameter file—you must issue additional `RESTORE` `CONTROLFILE` and `RESTORE` `SPFILE` commands to restore these files. If you specify the `CHECK` `READONLY` option, then RMAN examines the headers of all read-only datafiles and restores any that need restoring. Use an optional `SKIP` `TABLESPACE` `'tablespace_name'` argument to avoid restoring specified tablespaces, which is useful when you want to avoid restoring tablespaces containing temporary data. If you specify `SKIP` `FOREVER` `TABLESPACE`, then RMAN specifies the `DROP` option of `ALTER` `DATABASE` `DATAFILE` `...` `OFFLINE` when taking the datafiles that belong to the tablespace offline before the restore. The `DROP` option indicates that RMAN does not intend to recover these files and intends to drop their tablespaces from the database after the database is opened again. In other words, `FOREVER` indicates that RMAN never intends to do anything with the skipped tablespaces again.
`DATAFILE` datafileSpec | Restores the datafiles specified by filename or absolute datafile number. See Also: "datafileSpec"
`SPFILE` `[TO [PFILE]` `'``filename``']` | Restores a primary or standby server parameter file to the location from which it was backed up (default), or to a different location specified by the `TO` clause. RMAN cannot overwrite a server parameter file currently in use by the target database. Specify `UNTIL` or `TAG` options of `RESTORE` to restore older versions of the server parameter file. By default RMAN restores the most current server parameter file. If the server parameter file is lost, connect to the target (and catalog if used) and then run SET `DBID`. Run STARTUP `FORCE` `NOMOUNT` before running `RESTORE` `SPFILE` (with `FROM` `AUTOBACKUP` if in `NOCATALOG` mode). Then run `STARTUP` `FORCE` to restart the database with the restored server parameter file. See Also: "Restrictions and Usage Notes for the SET DBID Command"
`[FOR DB_UNIQUE_NAME` `'``DB_UNIQUE_NAME``']` | The `FOR DB_UNIQUE_NAME` clause for `RESTORE SPFILE` is only useful in a Data Guard environment. In a Data Guard environment, the primary and standby nodes may have different channel configurations for communicating with their associated SBT backup and disk devices. If both the primary and standby databases are known to the recovery catalog, then the configuration settings for both databases are recorded in the recovery catalog. Because the two databases have the same `DB_NAME`, the records in the recovery catalog can only be distinguished using the value of the `DB_UNIQUE_NAME` initialization parameter for the primary and standby databases. RMAN cannot determine the `DB_UNIQUE_NAME` initialization parameter for the target database if the SPFILE of the target database is not available, as is the case when restoring the SPFILE from backup. Therefore, RMAN cannot choose the correct channel configurations to use when restoring the SPFILE from backup at the target node. In such a circumstance, RMAN returns an RMAN-6758 error. The `FOR` `DB_UNIQUE_NAME` clause of the `RESTORE` command is used to specify the `DB_UNIQUE_NAME` in this situation. With the `DB_UNIQUE_NAME` , RMAN is able to locate the correct configuration settings for the node on which the SPFILE is being restored, and can use them to access backup devices. Note: Using `RESTORE SPFILE` when the `DB_NAME` is not unique in the recovery catalog produces an RMAN-6758 error. See Also: Oracle Data Guard Concepts and Administration for a detailed procedure for restoring the SPFILE in a Data Guard environment.
`STANDBY CONTROLFILE [ TO '``filename``' ]` | Restores the current control file for a standby database. See Also: Table 2-27 for restrictions and usage notes. Note: You must always run the RECOVER command after restoring a control file, and must also always open the database with the `RESETLOGS` option.
`TABLESPACE` `'tablespace_name'` | Restores all datafiles in the specified tablespaces. The translates the tablespace name internally into a list of datafiles. If you rename a tablespace (for example, from `users` to `customers`), then so long as an additional tablespace with the old name (`users`) has not been created, you can use either the old name (`users`) or the new name (`customers`) for the tablespace. RMAN detects that the tablespace has changed its name and updates the recovery catalog on the next resynchronization.

restoreSpecOperand

Syntax Element | Description
--- | ---
`restoreSpecOperand` | Specifies options for the `restoreObject` clause. Note: These parameters override the parameters with the same name at the `RESTORE` command level.
`CHANNEL` `'channel_id'` | Specifies the case-sensitive name of a channel to use for this restore operation. If you do not specify a channel, then `RESTORE` uses any available channel allocated with the correct device type.
`FROM` `AUTOBACKUP [autoBackupOptionList]` | Restores a control file autobackup. You can only specify this option on the `RESTORE` `CONTROLFILE` and `RESTORE` `SPFILE` commands. When restoring either type of file in `NOCATALOG` mode, the `FROM` `AUTOBACKUP` clause is required. RMAN begins the search on the current day or on the day specified with the SET `UNTIL`. On the first day searched, the search begins with sequence number 256 (or the sequence number specified by MAXSEQ, if provided) and counts back to sequence 0. If no autobackup is found in the current or `SET` `UNTIL` day, RMAN checks preceding days, starting with sequence 256 and counting back to 0. The search continues up to `MAXDAYS` days (default of 7, maximum of 366) prior to the current or `SET` `UNTIL` day. If no autobackup is found within `MAXDAYS` days, then RMAN signals an error and the command stops. See Also: Table 2-27 for restrictions and usage notes.
`FROM` `'``media_handle``'` | Specifies the name of the control file copy or backup piece containing a control file. The `media_handle` can be any backup piece that contains a backup of a control file: the control file backup does not need to be an autobackup. See Also: Table 2-27 for restrictions and usage notes.
`FROM` `TAG` [`=]` `'tag_name'` | Overrides the default selection of the most recent backups or file copy available. The tag restricts the automatic selection to backup sets or file copies that were created with the specified tag. If multiple backup sets or file copies have a matching tag, then RMAN selects the most recent one. Note that tag names are not case sensitive. See Also: "BACKUP" for a description of how a tag can be applied to an individual copy of a duplexed backup set, and for a description of the default filename format for tags

autoBackupOptList

Syntax Element | Description
--- | ---
`autoBackupOptList` | Parameters that control the search for a control file autobackup.
`DB_NAME = 'database_name'` | Provides a DB_NAME to be used in searching for control file autobackups.
`MAXDAYS =` `integer` | Limits the search for a control file autobackup to within the specified number of days in the past.
`MAXSEQ =` `integer` | Specifies the highest sequence number for the control file autobackup search.
`(RECOVERY AREA| DB_RECOVERY_FILE_DEST) =` `password` | Specifies path to flash recovery area to search for autobackups. `RECOVERY AREA` and `DB_RECOVERY_FILE_DEST` are synonyms.
`DB_NAME =` `database_name` | Provides the `DB_NAME` of the database in the specified flash recovery area that is the target of the restore operation.
`DB_UNIQUE_NAME =` `{` `identifier` `|` `quoted-string` `}` | Provides the `DB_UNIQUE_NAME` of the database in the specified flash recovery area that is the target of the restore operation.

Examples

Restoring a Tablespace: Example This example takes a tablespace offline, restores it, then performs media recovery:

    SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
    RESTORE TABLESPACE users;
    RECOVER TABLESPACE users;
    SQL "ALTER TABLESPACE users ONLINE";

Restoring the Control File When Using a Recovery Catalog: Example This example restores the control file to its default location, replicates it automatically to all `CONTROL_FILES` locations, and mounts the database:

    RUN
    { # SET DBID is not necessary when connected to a recovery catalog
      STARTUP FORCE NOMOUNT;
      RESTORE CONTROLFILE;
      ALTER DATABASE MOUNT;
    }

Restoring the Control File with a Tag: Example This `NOCATALOG` example restores the control file specified by a tag, and then mounts the database:

    CONNECT TARGET /
    STARTUP NOMOUNT;
    SET DBID 320066378;  # required when restoring control file in NOCATALOG mode
    RESTORE CONTROLFILE FROM TAG 'monday_cf_backup';
    ALTER DATABASE MOUNT;

Restoring the Database with a Backup Control File: Example This example restores the control file to a temporary location, replicates it to all control file locations specified in the `CONTROL_FILES` initialization parameter, and then restores and recovers the database:

    CONNECT TARGET /
    STARTUP NOMOUNT;
    SET DBID 320066378;  # required when restoring control file in NOCATALOG mode
    RUN
    {
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
      RESTORE CONTROLFILE FROM AUTOBACKUP;
      ALTER DATABASE MOUNT;
      RESTORE DATABASE;
      RECOVER DATABASE;
    }
    ALTER DATABASE OPEN RESETLOGS;

Restoring Archived Redo Logs to a New Location: Example This example restores all archived redo logs to the `/oracle/temp_restore` directory:

    RMAN> RUN
    {
      SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
      RESTORE ARCHIVELOG ALL;
    }

Restoring a Control File Autobackup to a Nondefault Location: Example This example restores the latest control file autobackup made on or before June 23, 2000 with a nondefault format of `PROD_CF_AUTOBACKUP_%F`. It starts searching for backups with a sequence number of 20, and searches backward for 5 months:

    RMAN> SET DBID 320066378;  # required when restoring control file in NOCATALOG mode
    RMAN> RUN
    {
      SET UNTIL TIME '23-JUN-2001 00:00:00';
      SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt TO 'prod_cf_autobackup_%F';
      ALLOCATE CHANNEL CHANNEL_1 DEVICE TYPE sbt;
      RESTORE CONTROLFILE TO '/tmp/autobackup_20001002.dbf' FROM AUTOBACKUP
        MAXSEQ 20 MAXDAYS 150;
    }

Restoring the Server Parameter File to Current Location: Example The following series of commands restores the current server parameter file in `NOCATALOG` mode:

    rman TARGET /
    RMAN> SET DBID 1447326980 # set dbid to dbid of target database
    RMAN> STARTUP FORCE NOMOUNT; # start instance with dummy SPFILE
    RMAN> RUN
    {
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
      RESTORE SPFILE FROM AUTOBACKUP; # FROM AUTOBACKUP needed in NOCATALOG mode
    }
    RMAN> STARTUP FORCE; # start with restored SPFILE and open database

Identifying Needed Backups with RESTORE... PREVIEW: Example The following example shows the results of a `RESTORE PREVIEW`, which identifies the backupsets RMAN selects for use in restoring archivelogs from backup. (Note that in this output, one of the archivelog backups is stored remotely.)

    RMAN> restore archivelog all preview;

    Starting restore at 10-JUN-05
    using channel ORA_DISK_1
    using channel ORA_SBT_TAPE_1

    List of Backup Sets
    ===================

    BS Key  Size       Device Type Elapsed Time Completion Time
    ------- ---------- ----------- ------------ ---------------
    31      12.75M     SBT_TAPE    00:00:02     10-JUN-05
            BP Key: 33   Status: AVAILABLE  Compressed: NO  Tag: TAG20050610T152755
            Handle: 15gmknbs   Media: /v1,15gmknbs

      List of Archived Logs in backup set 31
      Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
      ---- ------- ---------- --------- ---------- ---------
      1    1       221154     06-JUN-05 222548     06-JUN-05
      1    2       222548     06-JUN-05 222554     06-JUN-05
      1    3       222554     06-JUN-05 222591     06-JUN-05
      1    4       222591     06-JUN-05 246629     07-JUN-05
      1    5       246629     07-JUN-05 262451     10-JUN-05

    BS Key  Size       Device Type Elapsed Time Completion Time
    ------- ---------- ----------- ------------ ---------------
    32      256.00K    SBT_TAPE    00:00:01     10-JUN-05
            BP Key: 34   Status: AVAILABLE  Compressed: NO  Tag: TAG20050610T153105
            Handle: 17gmknhp_1_1   Media: /v1,17gmknhp_1_1

      List of Archived Logs in backup set 32
      Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
      ---- ------- ---------- --------- ---------- ---------
      1    6       262451     10-JUN-05 262547     10-JUN-05
      1    7       262547     10-JUN-05 262565     10-JUN-05

    List of remote backup files
    ============================
            Handle: 15gmknbs   Media: /v1,15gmknbs

Recalling Vaulted Backups from Remote Storage with RESTORE... PREVIEW RECALL: Example When used with a media manager that reports information about remote storage of backups and supports recalling vaulted backups, the following command requests that any media needed in the restore of archivelogs from backup be recalled from remote storage:

    RMAN> RESTORE ARCHIVELOG ALL PREVIEW RECALL;
    Starting restore at 10-JUN-05
    using channel ORA_DISK_1
    using channel ORA_SBT_TAPE_1

    List of Backup Sets
    ===================

    BS Key  Size       Device Type Elapsed Time Completion Time
    ------- ---------- ----------- ------------ ---------------
    31      12.75M     SBT_TAPE    00:00:02     10-JUN-05
            BP Key: 33   Status: AVAILABLE  Compressed: NO  Tag: TAG20050610T152755
            Handle: 15gmknbs   Media: /v1,15gmknbs

      List of Archived Logs in backup set 31
      Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
      ---- ------- ---------- --------- ---------- ---------
      1    1       221154     06-JUN-05 222548     06-JUN-05
      1    2       222548     06-JUN-05 222554     06-JUN-05
      1    3       222554     06-JUN-05 222591     06-JUN-05
      1    4       222591     06-JUN-05 246629     07-JUN-05
      1    5       246629     07-JUN-05 262451     10-JUN-05

    BS Key  Size       Device Type Elapsed Time Completion Time
    ------- ---------- ----------- ------------ ---------------
    32      256.00K    SBT_TAPE    00:00:01     10-JUN-05
            BP Key: 34   Status: AVAILABLE  Compressed: NO  Tag: TAG20050610T153105
            Handle: 17gmknhp_1_1   Media: /v1,17gmknhp_1_1

      List of Archived Logs in backup set 32
      Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
      ---- ------- ---------- --------- ---------- ---------
      1    6       262451     10-JUN-05 262547     10-JUN-05
      1    7       262547     10-JUN-05 262565     10-JUN-05

    Initiated recall for the following list of remote backup files
    ==========================================================
            Handle: 15gmknbs   Media: /v1,15gmknbs
    Finished restore at 10-JUN-05

Validating a Restore with RESTORE VALIDATE: Example The following example illustrates using `RESTORE... VALIDATE` to confirm that backups required for the restore of datafile 1 are present on disk or tape, readable, and not corrupted:

    RMAN> RESTORE DATAFILE 1 VALIDATE;

    Starting restore at 10-OCT-03
    using channel ORA_DISK_1

    channel ORA_DISK_1: starting validation of datafile backupset
    channel ORA_DISK_1: restored backup piece 1
    piece handle=/disk1/oracle/work/v1/0pf3hr3o_1 tag=FOURTH_INC
    channel ORA_DISK_1: validation complete
    Finished restore at 10-OCT-03